1. Field of the Invention
The present invention relates to a computer program product, system, and method for establishing copy pairs from primary volumes to secondary volumes in multiple secondary storage systems for a failover session.
2. Description of the Related Art
Failover programs, such as International Business Machine Corporation's (“IBM”) HyperSwap® which is a function in the z/OS® operating system, provides continuous availability for disk failures by maintaining synchronous copies of all primary disk volumes on one or more primary storage systems to one or more target (or secondary) storage systems. (HyperSwap is a registered trademark of IBM in countries throughout the world). When a disk failure is detected, code in the operating system identifies HyperSwap managed volumes and instead of failing the I/O request, HyperSwap switches (or swaps) information in internal control blocks so that the I/O request is driven against the secondary volume. Since the secondary volume is an identical copy of the primary volume prior to the failure, the I/O request will succeed with no impact to the program issuing the I/O request, which could be an application program or part of the operating system. This therefore masks the disk failure from the program and avoids an application and/or system outage. An event which causes a HyperSwap to be initiated is called a “swap trigger”.
Periodically HyperSwap checks the environment including the I/O configuration to assure that no changes have occurred such that a HyperSwap is no longer possible. If there exists a problem in the configuration HyperSwap will indicate that it is either running in degraded mode or it may become completely disabled. In either case, if a HyperSwap occurred after the problem was detected some or all of the systems in the sysplex (or computing cluster) may not be able to HyperSwap. When this happens the programs accessing the effected devices will fail which often means the entire system or sysplex will fail.
When a swap trigger is detected, HyperSwap first verifies that the target configuration is still viable by running the check one last time. If the configuration is still viable then the HyperSwap proceeds. Otherwise, if invalid, depending on policy, the HyperSwap is either terminated and backed out if required or systems that cannot proceed with the HyperSwap are partitioned out of the sysplex in an attempt to allow other systems in the sysplex to complete the HyperSwap.